fix: zombie connection after stream-error 500 (ClientPayload + receipt compliance) - #630

DeviceCommand::IncrementLoginCounter has been defined, persisted, and
unit-tested since the audit commit but was never dispatched, so `lc`
stayed at 0 across every login. WA Web bumps it after each successful
auth (Start/Backend.js listener on `onOpenSocketStream`, fired by Comms
`onConnect` post-handshake). A flat-zero counter is one of the server's
anti-abuse signals — combined with the rotating phone_id fixed in the
previous commit, the result was the zombie-session symptom.

Dispatched from the existing post-success spawn in handle_success, right
after the LID-update block. process_command() flushes synchronously so
the next handshake reads the bumped value.

WA Web (Handle/MsgSendReceipt.js + Send/DeliveryReceiptJob.js) acks
status@broadcast messages with `<receipt context="status">`, not <ack>.
This port had it inverted:

  should_ack:                 status_broadcast => true (sent <ack>)
  send_delivery_receipt:      status_broadcast => skipped

So status messages were getting the wrong wire shape, and the
delivery-receipt code path never ran for them.

Fix: drop status_broadcast from should_ack (newsletter is the only
<message> tag that needs <ack> on the success path), let
send_delivery_receipt cover it, and add the `context="status"` attr
when chat.is_status_broadcast().

The receipt node assembly is extracted to a pure
build_delivery_receipt_node() helper so unit tests can assert wire
shape without spinning a transport. Adds:

  - delivery_receipt_for_status_broadcast_carries_context_status
  - delivery_receipt_for_dm_has_no_context_no_participant
  - delivery_receipt_for_group_carries_participant
  - should_send_delivery_receipt_allows_status_broadcast
  - should_send_delivery_receipt_skips_newsletter

Updates test_ack_behavior_for_incoming_stanzas to assert the new
contract for status@broadcast.

WA Web's Send/DeliveryReceiptJob.js gates the participant attr on
`(t.isGroup() || t.isBroadcast()) && r`, so status broadcasts (which
are isBroadcast=true but isGroup=false) also carry the original
poster's JID. Without it the server can't map the ack back to the
status owner and may keep retrying delivery.

Updates build_delivery_receipt_node to extend the gate, and tightens
the unit test to assert both context="status" AND the participant.

Adds defensive tests covering:
  - peer-msg DM (type=peer_msg, no participant/context)
  - status broadcast that happens to be category=Peer
    (participant + context must still be set)
  - should_send_delivery_receipt edge cases: empty id, own DM,
    own peer-msg

Comms/Config.js gates `triggerOpenSocketStream` (which fires the
incrementLoginCounter listener registered in Start/Backend.js) on
`WAWebUserPrefsMultiDevice.isRegistered()`. So WA Web does NOT bump
the counter during the XX handshake of the pairing flow — only on
subsequent IK logins.

The previous commit dispatched unconditionally on every <success>,
which would push the first post-pair login to `lc=1` instead of the
expected `lc=0`. Counter is still monotonic so the server tolerates it,
but it's a measurable wire diff vs the official client.

Mirror the gate by reading `device.pn` from the persistence snapshot
(set during pairing) and skipping the bump while it's None.

Adds `registration_payload_does_not_carry_lc` so a future refactor of
the registration path can't silently leak the field.